Date: Mon, 19 Apr 93 04:30:02 PDT 

From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu> 
Errors-To: Packet-Radio-Errors@UCSD.Edu 

Reply-To: Packet-Radio@UCSD.Edu 

Precedence: Bulk 

Subject: Packet-Radio Digest V93 #106 

To: packet-radio 


Packet-Radio Digest Mon, 19 Apr 93 Volume 93 : Issue 106 


Today's Topics: 
9K6 Half-Duplex Parameters ?? 
FBB mail list? 
GRAPES & 56K at Dayton Hamvention 
method for improving packet thruput in noisy channels (well, maybe) 
Need mb1501.exe file 
TR-7950 mod for 9600b packet operation 


Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu> 
Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Packet-Radio Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: 18 Apr 93 20:18:47 +1000 

From: munnari.oz.au!bunyip.cc.uq.oz.au!news.qut.edu.au!qut.edu.au! 
joyce@uunet.uu.net 

Subject: 9K6 Half-Duplex Parameters ?? 

To: packet-radio@ucsd.edu 


Hi, There is a small group of user's here in Brisbane Australia thats 
testing 9600 baud G3RUH modems in HALF-DUPLEX mode for a user-level onto 
a main back bone. Can anyone help with known PARAMETERS for HALF-DUPLEX 
mode @ 9600 baud, we have been starting around with the param's within 
the G3RUH paperwork but the through put seems very poor. Any help would 
be very much appreciated. 


Thanks in advance... 


Andy Joyce VK4KIV. 


Andy Joyce VK4KIV AMPRNet: vk4kiv@vk4kiv.qut.ampr.org 
QUT Kedron Park Campus Internet: joyce@vk4kiv.qut.edu.au 
TCP/IP Co-ordinator VK4 Email2: A.joyce@qut.edu.au 


Date: Sun, 18 Apr 1993 23:46:20 GMT 
From: wyvern! lbyrd@uunet.uu.net 
Subject: FBB mail list? 

To: packet-radio@ucsd.edu 


Is there an FBB mail list available? I would like to forward it to local 
BBS sysops since they all run FBB.. Please e-mail to 
Lbyrd@wyvern.wyvern.com. Thanks very much. 


Lbyrd@wyvern.wyvern.com Tel: (804) 482-3933 
Alt: Lyman@attwat.twuug.com wa4yse@kj41q.va.usa.noam 


Date: Mon, 19 Apr 1993 03:15:17 GMT 

From: usc!wupost! emory!kd4nc!dug@network.UCSD.EDU 
Subject: GRAPES & 56K at Dayton Hamvention 

To: packet-radio@ucsd.edu 


GRAPES will be represented at the Dayton Hamvention in Flea Market 
space 3341 and 3342. 


KD4NC, KD4APM and KE4ZV will be at the flea table (off and on as usual), 
speaking of 56K, packet networking and other topics (nothing new, really)... 


We WILL have kits available at the Hamvention. 
We're expecting guest appearances from the Ottawa group (Doug Yuill, 


No plans for demos (wasn't sure if Phil would be available to fix 
the generator :-> ) 


Not to take away from the TAPR booth as a gathering space (we'll be 
visiting there often to see who comes around).. but we 

would like to visit with fellow 

packeteers/experimenters/network builders/USENETr's.. Stop 

by and visit us when you are trudging around in the flea market... 


We also look forward to meeting up with fellow packeteers at McNasty's 
on Saturday night... 


BTW, If ANYONE see's any 220 or 430 transverters for sale, PLEASE PLEASE let us 
know... 


Doug Drye KD4NC 


Doug Drye KD4NC (dug@kd4nc.atl.ga.us) 


Date: Mon, 19 Apr 1993 03:32:53 GMT 

From: usc!howland.reston.ans.net!wupost!uwm.edu!linac!att!att-out!cbf£sb! 
cbnewsb.cb.att.com!wa2ise@network.UCSD.EDU 

Subject: method for improving packet thruput in noisy channels (well, maybe) 
To: packet-radio@ucsd.edu 


Better packet reception 


How about this method for improving packet reception (probably has been 
done, but here goes anyway). Sometimes, when noise causes a few errors 

in a received packet, the CRC rejects the packet and tells the transmitting 
station to resend it. If the noise persists, you are in for a lot of 
retries, and thruput is bad. Let's say, for example, that the received 
packets have about 5 errors. 


Suppose the receiving TNC stores the bad packet. and if the next try is 
also bad, store it. And if the third try is also bad, you could compare 
all three, byte by byte, and look for where they differ. Errors should 
be at random spots in relation to each other in the 3 stored bad retries. 
You could do a reconstruction of a (hopefully) good packet by noting, on 
a byte by byte basis, which two of the three match, and use that value 
in the reconstruction. (If all three are different, you have to ask 

for a 4th retry, but that shouldn't happen too often, or if it does, 

the channel is really bad!). After you reconstruct a packet, do the CRC 
to verify it. If it passes, then you tell the transmitting station 

that you received it OK, and send the next new packet. Transmitting 

TNC needs no mods, just the recieving TNC can be modified. Transmitter 
doesn't even know that the receiver has this. 


example packet retries: 


1 The quick brown dof jumps over the lazt fox. CrC 

2 Tye quicj brown dog jumpa over the lazy fOx. CRC 

3 The quick briwn dog jumps ocer the lazy fox. CRC 
AN AN 


AN A AN AN A AN AN 


places where 1 of 3 do not match, use the character which has a pair matching. 


R The quick brown dog jumps over the lazy fox. CRC 
AN AN AN AN AN AN AN AN AN 
replaced characters. * 
* (I realize that the CRC doesn't look like this, but I just wanted to 
illustrate the possibility of reconstructing it as well) 


The algorthym would probably be: look for a matching pair, then use that 
character. Don't care if the 3rd character matches or not. Maybe 
measure amount of all 3 match to evaluate s/n and confidence levels. 
Then do a CRC on the reconstruction using a reconstructed (if necessary) 
CRC value. If still bad, ask for a 4th retry, and look for a pair out 
of the 4 values at that position that had no pair before, or try to 

make a new CRC and use it. 


Don't know if this is usually done ("Don't you know that this is called 
‘digital blah blah ba blah', anyone who had 'Packet 101 knows that!"), or maybe 
the extra s/n margin this would buy is too small to be worth the trouble? 

It's just some more code in the TNC's EPROM, and a little more use of 
scratchpad RAM, which room probably exists already without increasing 

parts count or cost. Just an increase of the time for someone to write it. 
(No, I don't have the programming skills to try this myself, unfortunately). 


Date: Sun, 18 Apr 93 22:23:58 GMT 

From: usc!howland.reston.ans.net!noc.near.net!oz.plymouth.edu! 
m_ander@network.UCSD.EDU 

Subject: Need mb1501.exe file 

To: packet-radio@ucsd.edu 


Hello, 
I need the version of mb1501 that was at ucsd.edu (they only have 
1505x.exe now, go figure). If you have a copy, please email it to me. 


Thanks, 


Mike 
m_ander@oz.plymouth.edu 


Date: 18 Apr 93 13:22:50 GMT 

From: news-mail-gateway@ucsd.edu 

Subject: TR-7950 mod for 9600b packet operation 
To: packet-radio@ucsd.edu 


I checked an internet mods server and didn't see any mods to set up 
a Kenwood TR-7950 for 9600b operation. Does anyone have the mod for 
that? Does anyone have any experience with 9600b with the TR-7950? I 
believe that the TR-7930 is the same rig, but has less output, so mods 
for that rig should be ok too. Thanks. 


73's de Jack - kf5mg 


AMPRnet - kf£5mg@kf5mg.ampr.org - 44.28.0.14 
AX25net - kf5mg@kf5mg.d4tdfw.tx.usa.na - work (817) 962-4409 
Internet - kf£5mg@vnet.ibm.com - home (817) 488-4386 


End of Packet-Radio Digest V93 #106 
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